Skip to content

Conversation

@pfultz2
Copy link
Contributor

@pfultz2 pfultz2 commented Jul 9, 2025

This removes the object libraries and uses normal cmake targets. This helps simplifies a lot of the cmake since we can properly propagate usage requirements.

@pfultz2
Copy link
Contributor Author

pfultz2 commented Jul 9, 2025

Because of the global registration an object library will need to be used for at least cppcheck-core, but we can still wrap it in an interface library so it can propagate usage requirements though.

@firewave
Copy link
Collaborator

firewave commented Jul 9, 2025

Using interface libraries would be an acceptable modernization (although I personally detest them - I had to many problems with them in the past). We need to test though that things work with the currently specified minimum CMake version and raise it appropriately if necessary.

But if we actually want to support shared libraries there is a lot of work to be done:

  • visibility handling on non-Windows platforms
  • needs to add annotation to all exported symbols (currently it was only set for the ones actually used in tests)
  • needs ABI handling/versioning for the shared objects
  • adjust the install targets
  • adjust the shipped Visual Studio project to generate the same output files
  • adjust the Windows installer
  • CI jobs to test this on all platforms
  • ... possibly even more things I cannot think off the top of my head

And IMO externals should not be shared libraries.

Also we still have static objects in our code which possibly makes the proper usage of the shared objects impossible. Beside that I reckon there never was and never will be a single user of the shared objects. And the current implementation was only partial.

We should not be supporting shared libraries at all because it just causes more work now and in the future and I do not see any upsides at all. We should be removing features instead of adding and simplifying things instead of making them even more complex (with latter I am referring to the support matrix - not the code).

@pfultz2
Copy link
Contributor Author

pfultz2 commented Jul 9, 2025

The purpose of the shared libraries would only be for local dev. I wouldn't envision us installing them.

@firewave
Copy link
Collaborator

firewave commented Jul 9, 2025

The purpose of the shared libraries would only be for local dev.

Please elaborate. I do not see how it would be of any use - especially given that it was never available and nobody complained. And if we want to support that we need to test it i.e. CI workflows. Otherwise it is just more stuff which rots away in this repo.

I wouldn't envision us installing them.

It would be possible but it would not work - so it should not be allowed.

@pfultz2
Copy link
Contributor Author

pfultz2 commented Jul 9, 2025

So with this change there is new -Wsuggest-attribute=noreturn warnings. I am not sure why we didnt warn before. I dont see us disabling warnings. Do you know why?

@pfultz2
Copy link
Contributor Author

pfultz2 commented Jul 9, 2025

Please elaborate. I do not see how it would be of any use

Faster linking time.

endif()

target_include_directories(tinyxml2 SYSTEM PUBLIC .)
target_include_directories(tinyxml2 PUBLIC .)
Copy link
Collaborator

@firewave firewave Jul 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That flag needs to depend on the EXTERNALS_AS_SYSTEM option.

Comment on lines 73 to 75
# if (NOT CMAKE_DISABLE_PRECOMPILE_HEADERS)
# target_precompile_headers(cppcheck-core-private PRIVATE precompiled.h)
# endif()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs to be enabled again before merging.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, that was to test the CI. I was getting error:

../../../lib/CMakeFiles/cppcheck-core-private.dir/cmake_pch.hxx.gch: file not recognized: file format not recognized

Now with it disabled I get an error that there isnt a make rule for it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, you are explicitly building it in selfcheck, but its using the wrong target name.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switching to the OBJECT library directly fixed this issue.

if (BUILD_CORE_DLL)
target_compile_definitions(tinyxml2_objs PRIVATE TINYXML2_EXPORT)
endif()
add_library(tinyxml2 ${srcs} ${hdrs})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be able to become a shared library.

if (BUILD_CORE_DLL)
target_compile_definitions(simplecpp_objs PRIVATE SIMPLECPP_EXPORT)
endif()
add_library(simplecpp ${srcs} ${hdrs})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be able to become a shared library.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will if we set BUILD_SHARED_LIBS.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then everything becomes a shared library which is not what we want. IMO the shared library stuff in the Windows build should be completely dropped. And I still thing this should not be real libraries since they are not actually reusable.


add_library(frontend_objs OBJECT ${hdrs} ${srcs})
target_include_directories(frontend_objs PRIVATE ${PROJECT_SOURCE_DIR}/lib)
add_library(frontend OBJECT ${hdrs} ${srcs})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this can become a shared library (which it shouldn't) it also needs the import/export handling. This is getting way more complicating than the existing code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this can become a shared library (which it shouldn't) it also needs the import/export handling.

Only on windows is that needed. Either way the purpose of this PR is not to support shared libraries.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated to this comment, this library shouldn't be an object library. I am not sure why its working.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see why this works. Since cmake 3.12, object libraries can be linked directly instead of adding the $<TARGET_OBJECTS> to the sources. This will make it simpler.

@firewave
Copy link
Collaborator

Faster linking time.

Yes, that probably will save a few microseconds...

Unlike the precompiled headers you just disabled which will actually save a lot of compilation time...

So with this change there is new -Wsuggest-attribute=noreturn warnings. I am not sure why we didnt warn before. I dont see us disabling warnings. Do you know why?

How do these occur? I did not see them in the CI failures.

const int res = _pclose(p);
#else
const int res = pclose(p);
int res = pclose(p);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixes (among others) in macos-15 builds:

/Users/runner/work/cppcheck/cppcheck/cli/cppcheckexecutor.cpp:746:9: warning: cast from 'const int *' to 'int *' drops const qualifier [-Wcast-qual]
  746 |     if (WIFEXITED(res)) {
      |         ^
/Applications/Xcode_16.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.0.sdk/usr/include/sys/wait.h:152:26: note: expanded from macro 'WIFEXITED'
  152 | #define WIFEXITED(x)    (_WSTATUS(x) == 0)
      |                          ^

Failing builds on warnings is tracked via https://trac.cppcheck.net/ticket/12021.

Copy link
Contributor Author

@pfultz2 pfultz2 Jul 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its needed to fix CI, because they became errors in the CI with these changes. I am not sure why it didnt error out before in the CI.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The scope is getting way too big with a lot of questionable sidecar changes. This needs to be fixed more incrementally.

Its needed to fix CI, because they became errors in the CI with these changes. I am not sure why it didnt error out before in the CI.

That should not be happening. That indicates that something is wrong in these CMake change.

@pfultz2
Copy link
Contributor Author

pfultz2 commented Aug 11, 2025

@firewave Are you able to review this?

@sonarqubecloud
Copy link

@firewave
Copy link
Collaborator

@firewave Are you able to review this?

Thanks for the extensive description.

I will take another look at this soon - need to take care of things which piled up in the past few weeks.

The first time I looked at this I saw some different shortcomings in the existing code which need to be singled out/addressed first but I cannot remember what it was.

My aim is to have this resolved in this dev cycle.

@gruenich
Copy link
Contributor

  • I think most changes are an improvement and should be merged.
  • I would drop the non-CMake changes (74f853f, 91afb23) from this pull request and create one for them alone.
  • Several of the commits should be squashed together and get a better commit message with some explanations. (If nobody is willing, I can do so and prove an alternative pull request).

@pfultz2
Copy link
Contributor Author

pfultz2 commented Aug 18, 2025

I would drop the non-CMake changes (74f853f, 91afb23) from this pull request and create one for them alone

The changes are needed to fix the compiler warnings in CI otherwise this PR cant be merged.

Several of the commits should be squashed together and get a better commit message with some explanations. (If nobody is willing, I can do so and prove an alternative pull request).

All of the commits are usually squashed when it gets merge.

@firewave
Copy link
Collaborator

The changes are needed to fix the compiler warnings in CI otherwise this PR cant be merged.

That's why I am working on making the CI bail out on compiler warnings (and fixing them) right now. When that is done this will be next.

@pfultz2
Copy link
Contributor Author

pfultz2 commented Sep 18, 2025

I removed the warning fix.

@pfultz2
Copy link
Contributor Author

pfultz2 commented Sep 19, 2025

@firewave I think this can be merged now.

@firewave
Copy link
Collaborator

Should be rebased after the warnings stuff is all in (I hope that is finally done by tomorrow). And I think I have looked into most of the side tracks of this already - will have another look at it later.

@firewave firewave removed the merge-after-next-release Wait with merging this PR until after the next Release label Sep 23, 2025
@firewave
Copy link
Collaborator

While looking into something completely unrelated I stumbled into some shortcomings in the GUI CMake which tied back into #7835, so that probably also needs to be merged first. 😕

@pfultz2
Copy link
Contributor Author

pfultz2 commented Sep 26, 2025

Should be rebased after the warnings stuff is all in (I hope that is finally done by tomorrow). And I think I have looked into most of the side tracks of this already - will have another look at it later.

I merged the latest last week, and there is no need for warnings fix. Everything is green, this can be merged in now.

While looking into something completely unrelated I stumbled into some shortcomings in the GUI CMake which tied back into #7835, so that probably also needs to be merged first.

No, that fix should build on top of this. This PR has already been open for almost 3 months, it should be merged in now.

@firewave
Copy link
Collaborator

firewave commented Oct 7, 2025

I am currently out with a worsening cold.

@pfultz2
Copy link
Contributor Author

pfultz2 commented Oct 28, 2025

@firewave @danmar Can you this be merged now? Its been open long enough and it causing merge conflicts.

@firewave
Copy link
Collaborator

Still a lot of things in here I have to look at more closely which I unfortunately didn't get around to yet. And there's still way more important things for me to look into then this.

)
target_include_directories(dmake PRIVATE ${CMAKE_SOURCE_DIR}/cli ${CMAKE_SOURCE_DIR}/lib)
target_externals_include_directories(dmake PRIVATE ${CMAKE_SOURCE_DIR}/externals/simplecpp)
target_link_libraries(dmake cppcheck-core cli simplecpp)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will get rid of the matchcompiler hack but I do not like that it now requires the whole libraries to build this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you dont want the whole library then it needs to be separated into a smaller library that can be shared among the components instead. That can be done in a later PR.

@@ -1,68 +1,37 @@
if (BUILD_CLI)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like we will do CLI stuff in CMake even if the CLI is disabled and that seems to defeat the purpose to disable it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its a dependency for dmake which seems required even if CLI is disabled.

Comment on lines 43 to 48
if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
# caused by mocks
target_compile_options_safe(test-resultstree -Wno-suggest-attribute=noreturn)
endif()


Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Duplicated - can be removed.

endif()
if (Boost_FOUND)
target_include_directories(cppcheck-core SYSTEM PRIVATE ${Boost_INCLUDE_DIRS})
target_include_directories(cppcheck-core SYSTEM PUBLIC ${Boost_INCLUDE_DIRS})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Boost should not be spilled from this library.

Copy link
Contributor Author

@pfultz2 pfultz2 Oct 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its used in the header files. If you dont want it to "spill out" then you will need to refactor it to stay in a .cpp file only. That can be done in a later PR.

@firewave
Copy link
Collaborator

Still a lot of things in here I have to look at more closely which I unfortunately didn't get around to yet. And there's still way more important things for me to look into then this.

Some clarification. Because of ongoing various personal issues it's often hard for me to concentrate on bigger tasks so I tend to look at some of my (not the one of others) older stuff/backlog or low-hanging fruits which usually requires less focused work rather than just some cleaning up. And I also try to avoid things which involve discussions. It also annoys me especially in case of external submissions.

@sonarqubecloud
Copy link

@pfultz2
Copy link
Contributor Author

pfultz2 commented Oct 28, 2025

Some clarification. Because of ongoing various personal issues it's often hard for me to concentrate on bigger tasks so I tend to look at some of my (not the one of others) older stuff/backlog or low-hanging fruits which usually requires less focused work rather than just some cleaning up. And I also try to avoid things which involve discussions. It also annoys me especially in case of external submissions.

Sure, hope you feel better soon. I dont think you need to be a blocker for this.

@danmar @chrchr-github @orbitcowboy Can you review and merge this PR since @firewave is not able to right now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants